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Preliminary Space Station User Operations Interface Plan 


Introduction 

This document is intended to be used by prospec- 
tive payload developers and Space Station Program per- 
sonnel to aid them in preparing schedules, estimating 
cost and personnel resources, and planning user flow 
through the Space Station system. The backbone of this 
document is a preliminary time-ordered listing of the 
deliverables and general technical content of informa- 
tion and equipment which needs to pass among Space 
Station users, user sponsors, and the Space Station 
Program throughout the lifecycle of a user’s activity with 
the Program. 

The plan in this document is centered on a 
“generic” payload installed on the manned base. Using 
this plan, later efforts may define interface plans for 
other user classes such as an equivalent to Shuttle 
“Getaway Specials”, quick-integration (or “Quick is 
Beautiful”) users, and others (Ref. 1). Very complex 
payload interfaces, such as those for multiple-launch 
assembly and staging missions, will presumably have to 
be planned on a case-by-case basis. 

Information in this document is derived from work 
performed at JPL on User Operations Support defini- 
tion, User Operations Policy, User Documentation 
Development, investigator experience with Shuttle 
payloads, and preliminary results from Space Station 
Utilization Case Studies (Refs. 2, 3, 4,.5). Information 
about Space Station Program plans is derived from a 
number of sources, including the Space Station Opera- 
tions Task Force (OTF). The integration plan is based 
on the OTF’s User Integration Scenario (Ref. 6). 

This document comprises the final deliverable for 
JPL’s Customer Operations Planning task, originally 
sponsored by the Level B Customer Integration Office. 
The work was performed at the Jet Propulsion 
Laboratory, California Institute of Technology, under 
contract with the National Aeronautics and Space 
Administration. 


Recommendations 

1, The Program must create and establish the products 
(documentation, testbeds, forms, etc.), groups, 
offices and positions listed in the plan outlined in 
this report in time to be used by the developers of 
the first payloads to be launched to the Space Sta- 
tion. 


2. Because of the extreme complexity of the Space Sta- 
tion Program, the Program offices must exercise ut- 
most care to ensure that the interface between the 
Program and the user is clear, concise, and free of 
unnecessary burden on the user or the Program. 

3. The Program must be sure to have a single point of 
contact through which the user can secure all 
needed documents, consultations, negotiations, 
resources, etc. 


4, The Program must ensure that the information flow 
to the user is complete, timely, and — especially — 
that it is easily accessible to the user. Users must 
take care to have the latest information regarding 
policies, resources, capabilities, procedures, perfor- 
mance, reimbursement and other useful informa- 
tion to ensure that all necessary information is on 
hand when it is needed. This will also help to en- 
sure that there are no last-minute surprises for 
users that will adversely impact their investigations 
(as with time delays or increased cost). 

5. Updated information needed by the users should be 
regularly posted on TMIS so that users may ascer- 
tain whether the information they possess is the 
most up-to-date possible. Users and their sponsors 
should have access to TMIS as their principal 
medium of electronic communication with the 
Program. 


Background 

The Space Station Program will be very complex — 
and a large number of investigators will use the Space 
Station — so a well-defined and useful interface 
between the Program and the users must be developed 
to ensure efficient utilization. The most complete 
description of a user interface to date was set forth by 
the Space Station Operations Task Force (OTF). As a 
part of the OTF’s final report, a “User Integration 
Scenario” was outlined. To help clarify the OTF’s inter- 
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face and to point out where further definition is needed, 
the plan in this paper was mainly adapted from the text 
of the OTF’s scenario, and then augmented with input 
from other sources. 

The plan is presented in three columns. The first 
column shows actions that must be taken by any of the 
NASA offices of the Space Station Program. The 
second column lists actions taken by the user. The third 
column shows participation by user sponsors, such as 
the Office of Space Science and Applications, the 
Office of Commercial Programs, and the Office of 
Aeronautics and Space Technology. Originally, a 
fourth column was planned to show the actions’ time 
relative to launch. Unfortunately, a clear estimation of 
when a particular action should take place could not be 
extrapolated from the OTF’s scenario. Setting times to 
the actions in the scenario should be a top priority — 
this would show the Program very clearly that there is a 
limited amount of time left to complete the documents 
and form the groups and necessary offices to establish 
the user interface. 


The plan in this paper has been set out as much as 
possible in order of occurrence from top to bottom and 
from left to right. Since not all payloads are alike, 
however, it must be realized that deviations in order and 
timing may occur. It is thought, however, that the se- 
quence of events as outlined in this paper will be helpful 
to the Program and users in their understanding of the 
requirements for the user interface. 

Whenever additional steps beyond those noted in 
the OTF scenario could be identified or suggested, they 
were added (and are enclosed in [square brackets] for 
clarity). Because the OTF scenario outlines a proposed 
approach to the user interface, refinements will likely be 
introduced as the Program matures. We suggest that, as 
the Program interface definition evolves, the steps in the 
plan must be made more precise and relative timing 
should be determined to assist the Program in defining 
the most effective user interface possible. 


Ramifications of the Plan 
— to the Program 

Many of the documents, offices and other items 
noted in the plan do not exist at this time. In order for 
the Space Station Program to be ready for the first user, 
these products need to be fully specified and created in 
time to be utilized by the first user. Assuming that the 
first payload will be launched in 1994, the Space Station 
Multilateral Control Board must allocate the Station’s 
resources among the Partners, the U.S. Space Station 
User’s Board must allocate U.S. resources among the 


sponsoring NASA offices, and the sponsoring NASA 
offices must allocate their resources among disciplines 
and have issued Announcements of Opportunity no 
later than 1989. Level 1 documentation (Ref. 5) should 
be in the first user’s hands now, and levels 2 and 3 
should be ready by 1988. 


These dates are based on a reasonable estimation 
of the period required for an effective payload to be 
developed, flight qualified, and delivered. The 1989 
date leaves less than a two year lead time for the crea- 
tion and emplacement of the necessary administrative 
organizations and appropriate documentation. The 
creation of many of these actions, documents and of- 
fices haven’t yet been initiated, showing the need for 
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immediate action. 

Steps must be taken to streamline the user interface 
as much as possible for the users to get the most from 
the Program (Ref. 7). Printed documentation, which 
will be the first contact with the Program for most users, 
needs to be well defined, concise, consistent, and useful 
(Ref. 5). In order to pave the way for the investigators 
who will utilize the Space Station, the Program must act 
immediately to lay out a useful Program-to-user inter- 
face. 


— to Users and their Sponsors 

By reading the plan, users will get a general idea as 
to what will be required of them as they proceed 
through the Program. The Space Station is a complex 
system, and users must acknowledge that a certain 
period of time will elapse between the conception of an 
experiment and flight. Thousands of pages of documen- 
tation will pass between each user and the Program. 
Reviews will take place not only to ensure the safety of 
the user’s payload, but also to verify the compatibility of 
the payload with the goals of the sponsor and the 
capabilities of the Station. By having a realistic view of 
what is required before committing to the Program, 
users will be less likely caught off guard as Program 
requirements unfold before them. 

The sponsors will see not only what actions are 
required of them, but also will understand the complex 
process their users will be going through. The sponsors 
will be able to support their users better as they 
progress through the Program if they know in advance 
where problem areas lie. 


Unresolved Issues 
Three of the most apparent unresolved issues are 

listed below. Many more will likely be uncovered as dif- 

ferent offices begin detailed planning of the elements 
described in this plan. 

1, What is a “complete” range of Station resources (this 
plan, page 4, bottom of second column (original 
source: Ref 6, page III.D-8)) that would require a 
user to participate in the planning process? What 
does a user give up by entering the planning 
process later than this point? What provisions are 
made for “Quick is Beautiful” payloads, which 


near bottom of second column (original source: 
Ref. 6, page II.D-11)) to be presented to the 
Program for training purposes? Is this requirement 
necessary? 

3. If the “POIC coordinates user commands and con- 
solidates them for transmission via the SSSC, and 
also monitors all user ops to ensure conformance to 
execute ops plan and to detect any hazardous chan- 
ges or trends” (this plan, page 9, near center of first 
column (original source: Ref. 6, page III.D-12)), 
how does the concept of Telescience (or 
“teleoperations”) fit in? It seems that real-time 
operations are incompatible with this concept. 
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require “two high-fidelity copies” (this plan, page 7, 
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Overview of Planning Sequences 


Program Planning Ongoing a 
(Inter-Partner) 


CUP/TOP CUP/TOP CUP/TOP 


Sponsor Planning Ongoing a 
(Intra-Partner) 


Launch(N) | | Launch(N + 1) 


SEL LCH RET COM 
Payload Planning ... L\ rAN rAN rAN \ 
(User) 
Phases: i- 2— 3—— 4— 56 


Initiation and proof of concept coe ow Key 

Concept development; feasibility analysis; prelim design SEL = Select payload for flight 
Payload development; test & delivery; logistics planning =~ MAN = Manifest on Increment(N) 
Payload launch; installation; operation -LCH = Launch for Increment(N) 


Results analysis; lessons learned; phase out RET = = Return from orbit 
Payload optionally stays for additional increments COM = Completed mission 


Comments: 

1. The coordination of the CUPs and TOPs by the Partners is an ongoing process. 

2. The period between payload selection (SEL) and launch (LCH) may be as much as five years. This time 
should be “compressible” to less than one year for some simple and “Quick Response” payloads. Manifesting 
may occur at any time after selection. The pare of time between launch and return will be a minimum of 
approximately 45 days. 


3. It is useful to differentiate those planning activities that are ongoing (general operations planning) from the 
one-time events incurred by an individual payload. Therefore, top-level Program management activities are 
displayed on separate timelines that indicate how these activities drive the specific payload planning events. This 
could be broken out in more detail for various lower layers of organization as well. 

4, Payload planning for a given Flight Increment will depend the Station’s configuration during that Incre- 
ment, and on the Station’s capability to provide various resources to payloads (Ref. 8). Planning will also depend 
on any specific discipline emphasis or utilization theme selected for the Increment. Therefore, until the 
configuration and any mission theme is known, there are progressive uncertainties in the earlier (pre-launch) 
phases that require wide tolerance limits in discussing generic payload timelines related solely to launch date. 
However, the various activities that occur within each of the designated phases (or some such partitioning) can be 
discussed more reliably — then, each task can be related to the next upstream milestone (i.e., one month before 
manifesting, or launch minus 10 days). Also, payload developers must anticipate constraints and holding times 
imposed by payloads with which they are to be integrated. These estimated uncertainties also are perhaps less 
unwieldy if related to a sub-partitioning of pre-launch timelines, since presumably each payload comprising the 
Increment’s “cargo” will be subject to the same interim deadlines. 
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or 


Space Station User Integration Plan 


Actions by the Space Actions by the User Actions by the NASA 
Station Program Sponsor 


[Program Office distrib- 
utes list of all Program 
documentation, and 
distributes Level 1 
(intro & general info) 
and Level 2 (general 
solicitation of user 
interest) documenta- 
tion]* 


Multilateral Control 
Board's (MCB) Systems Ops 
Panel provides the MCB a 
projection of available 
user resources over the 
coming 5 years and 
recommends allocation to 
the Partners. 


MCB notifies Partners of 
available user 
resources. 


U.S. Space Station Users 
Board (SSUB) divides U.S. 
allocation among the 
user disciplines [i.e., 
sponsor offices]. 


The Office of Space The sponsor Program 
Station Ops’ (OSSO) Offices (User Codes) may 
Utilization and subdivide their resource 
Operations Development allocations into sub- 
Division (UODD) alerts blocks alloted to their 
the potential user component disciplines 
community via articles, (microgravity, Automation 
brochures, etc.,. but, & Robotics, astrophysics, 
the sponsor Program etc.) 


Offices bear primary 
responsibility for 
marketing. 


* Items enclosed in [square brackets] are steps and comments added by the 
author to what was included in the OTF scenario. 
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Program Actions User Actions NASA Sponsor Actions 


UODD provides sponsors 
specific cost and tech- 
nical info and develops 
standard forms for 
user/Station agreements. 


UODD or Office of 
Commercial Programs 
(OCP) perform outreach 
activities to attract 
commercial users. 


Proposal undergoes 
reviews to determine its 
compatibility with the 
goals, capabilities and 
constraints of the 
Program and the resource 
allocations. 


[Program provides 
sponsor offices with 
realistic cost estimates 
for Station use. ] 


Utilization and Ops Inte- 
gration Office (UOIO) 
uses MRDB to perform 
payload feasibility 
assessment against 
Station systems and ops. 


{Program issues Level 4 
documentation (Technical 
Utilization/Payload 
Development info) to 
user. ] 


User Integration Plan 


conduct Station utility 


NASA sponsors issue AOs 
and perform main 
marketing tasks. 


[User contacts OSSO or 
sponsor for info to 


[Sponsor distributes 
Level 3 documentation 
(describes utility and 
competitiveness of the 
Station for a particular 
application). } 


assessment. ] 


[User performs assess- 


ment of the Station’s 


utility to accommodate 


his particular need. ] 


User submits a formal 
proposal with UODD's [or 
sponsor's] assistance. 


Sponsor reviews proposal 
to determine 
compatibility with 
Sponsor's goals and 
selects from approved 
payloads for [payload] 
definition. 


User provides 
information for the 
Mission Requirements 
Data Base (MRDB). 


Sponsor provides user 
with "best effort” 
commitment to costs for 
access to Station. 


User develops a Request 
For Flight (RFF) form 
(similar to STS-100). 


User reviews [specific] 
restrictions and 
requirements the Program 
will impose on payload 
and activities [and makes 
required design updates]. 
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Program Actions User Actions NASA Sponsor Actions 


UOIO submits the RFF and 
formal proposal to SSUB 
for review. 


Payload (proposal) is 
evaluated by the Program 
for acceptance pending 
final approval by the 
MCB. 


Payloads (proposals) are 
forwarded to the User Ops 
Panel (UOP) for 
consolidation with 
payloads approved by 
other Partners. 


UOP combines all selected 
payloads into a Consoli- 
dated Utilization Plan 


- (CUP) and forwards it to 


MCB for final approval. 
The CUP lists all major 
utilization and ops 
activities planned for 
the next 5 years, and 
assigns payloads to a 
particular year and 
quarter and to a partic- 
ular transportation 
system. 


Space Station Associate 
Administrator signs off 
on the CUP and RFFs -- 
users have a commitment 
to fly. 


User Accommodations 
Integration Office 
assigns user a Payload 
Accommodation Manager 
(PAM). All requests 
from the Program to the 
user will be routed 
through the PAM. 


User Integration Plan 


[User, with help of 
Level 3 documentation 
and sponsor input, 
determines best 
transportation method 
and requests type of 
launch vehicle. ] 


Sponsors initiate 
payload development. 


User may utilize the PAM 
for contact with all 
offices in the Program 
or, if he choqgses, he may 
deal with these offices 
directly. 
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Program Actions User Actions NASA Sponsor Actions 


[Program provides design 
tools, interface 
templates, simulation and 
testbed facilities to aid 
user in payload 
development. ] 


{Program office issues 
Level 5 documentation 
(mission-specific). ] 


PAM arranges for initial 
(Phase-Zero) safety 
review. 


PAM arranges for reviews 
(including Phase-one 
safety review) and 
briefings with all 
institutional ops offices 
involved with supporting 
the payload. 


UOIO combines require- 
ments from all users 
(incl. Partner- 
nominated) to assign 
payloads to a new flight 
increment. The new 
increment is added to the 
Tactical Ops Plan (TOP). 


TOP is approved by all 
partners via the Program 
Ops Control Board (POCB). 
A crew is assigned. 


User Integration Plan 


User becomes a member of 
the Space Station User's 
Working Group (SSUWG). 


User develops Payload 
Integration Plan (PIP) 
and its annexes with 
assistance from his PAM. 


User assembles a 
development plan for 
payload and ground ops. 


Sponsor and PAM assist 
user create development 
and ground ops plans. 


User defines his require- 
ments for [sharing and] 
coordination with other 
users. 


User provides PAM with 
updated payload infor- 
mation (reflecting any 
changes made as a result 
of reviews) to support 
updates to MRDB, PIP, and 
PIP annexes. 


User enters the Program 
planning process if he 
requires a “complete” 
range of Station 
resources. Users 
entering the increment 
after this time will be 
restricted with regard 
to the range of payloads 
they can implement. 
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An Increment Change 
Manager is assigned to 
oversee all planning, 
ops, and integration. 
The TOP assigns primary 
Station ops, maintenance 
and servicing activity 
time intervals (but not 
detailed timelines or 
directions). 


The Systems Engineering 
and Integration Office 
(SE&IO) arranges for 
transportation and its 
manifests, and transpor- 
tation and data system 
manifest documentation, 
{for logistics and 
payloads]. 


TOP and manifests are 
forwarded to the Manned 
Base User Ops Office, the 
Manned Base Systems Ops 
Office, the Logistics Ops 
Office, and the Pre- and 
Post-Flight Ops office 
and developed into pre- 
and post-flight ops plans 
and Flight Increment 
Plans (including crew 
training and simulation 
plans, and logistics 
plans). 


Crew user training 
begins. If a [user's] 
payload scientist will 
operate the payload, he 
will be trained in 
Station ops. 


The TOP is sent to the 
Office of Space Tracking 
and Data Systems for 
development of TDRSS/ 
network ops plans. 


User Integration Plan 
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Office of Space Flight 
performs supportability 
assessment based on OSSO 
manifests. 


The Manned Base System 
Ops Office develops an 
Increment Hazard Control 
Plan, which is reviewed 


by the Ops Safety Office. 


Phase-Two safety review. 


Increment change manager 
coordinates assessments 
by the Space Station 
Support Center (SSSC), 
POIC and other offices. 


Based on assessments, an 


increment crew assigned. 


User Integration Plan 


All users in the 


increment join the 
Investigator Working 
Group (IWG) to partici- 
pate in execution-level 
planning. 


User trains ground ops 
facilities staff as 
necessary. Ground 
facilities will be 
required to provide all 
capabilities necessary 
to allow the user to 
perform any required 
teleoperations. 


User updates and refines 
payload requirements. 


User undergoes final ops 
assessments. 


Sponsor and PAM supports 
user through Preliminary 
Design Review. 


Sponsor assigns most of 
its users to a Discipline 
Ops Center (DOC) which 
will coordinate ops 
during flight preparation 
and execution (known as 
"discipline users”). 
Other users (esp. commer- 
cial) may choose to build 
their own User Ops 
Facility (UOF) which will 
link with the Station and 
other users via the DOC 
or the POIC (known as 
"direct users”). 


S&T Centers, Sponsors, 
POIC and PAM all support 
the user in developing 
payload, ops plans and 
ground facilities. 


PAM and Sponsor support 
assessments. 
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The user ops execution 
plan is consolidated by 
the SSSC with Station 


systems requirements into 


a preliminary Flight 
Increment Plan (FIP). 


SSSC updates resource 
envelope available to 
users; POIC adjusts 
resource assignments to 
the DOCs and other 
(direct) users. 


POIC develops integrated 
user ops execution plan. 


FIP finalized. Any 
changes made after this 
time are considered 
"replanning” . 


SSSC resolves conflicts 
between user and systems 
requirements. 


Conflict resolution 
process determines user 
resource envelope. 
Communications with 
payload and/or crew is 
planned for at this time 
as part of the envelope. 


Program provides 
training for user. 


User Integration Plan 


User participates in the 


development of the FIP, 


which is refined 


continuously until it is 
finalized. 


Users develop refined 


and updated ops plans 
based on new resource 
assignments. 


IWG approves the POIC's 
execution plans. 


IWG resolves conflicts 


between user 


requirements. 


User plans DOC or UOF 


activities within the 
resource envelope. 


At the user's site, user 


trains Station crew and 
ground personnel in the 
{goals,] ops and mainten- 
ance of his payload. 


If payload has "complex” 
requirements, user 
delivers two high- 
fidelity copies of his 
payload to the Program 
for use in simulation and 
training. 


User undergoes training. 
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Payload is integrated 
into experiment racks or 
carriers at the S&T 
center, at the launch 
site by the Pre- and 
Post-Flight Ops Office, 
or at integration 
facilities provided by 
the Partners in the U.S. 
or abroad, per the PIP. 


Racks are integrated {User supervises 
into logistic modules or integration to assure 
pallets. payload safety. ] 


User coordinates pro- 
vision of any necessary 
spares or supplies to 
Logistics Ops Office. 


Logistics Ops Office 
provides launch site 
storage and preservation 
facilities available. 


Program hands modules 
and carriers to Office 
of Space Flight (OSF), 
which integrates the 
modules and carriers 
into launch vehicle. 


User performs late 
payload access ops as 
necessary (e.g., animal 


feeding). 
{Launch } 
Crew installs new racks User issues commands 
and equipment and required to complete 
performs initial checkout and verifi- 
checkout. cation and oversees crew 


checkout activities. 


Increment Ops begin. 


User Integration Plan 
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Each day, SSSC updates IWG reps negotiate with 

the POIC on each Station POIC any changes to user 

system’s status; POIC plans to reflect any 

updates the IWG on status changes in the resource 

of user resource envelope, and coordinates 

envelope. changes to individual 


user plans. User reps 
negotiate new resource 
and time envelopes and 
forward modified consoli- 
dated plans to the POIC. 


POIC updates SSSC on User performs any ops 
user plans for originating from his UOF 
integration with Station and oversees any actions 
systems replanning data. taken by the crew. 

POIC coordinates user User monitors payload 


commands and consolidates data and, if necessary, 
them for transmission via can request additional 


the SSSC. POIC also resources through the IWG 
monitors all user ops to to accommodate unforseen 
ensure conformance to results. Any changes in 
ops plans and to detect ops (including any 

any hazardous changes or contingency ops) must be 
trends. SSSC monitors approved within the IWG, 
system status and ensures POIC and SSSC prior to 
that user ops don’t implementation. 


adversely affect safety 
of crew or Station. 


[Flight increment nears If payload will remain 

completion. ] _ for next increment, user 
forwards any changes in 
resource requirements to 
UOIO for inclusion in 
next increment’s plan. 


Changes in resource 
requirements for carry- 
over payloads are 
approved by POCB. 


[Flight increment ends. ] User shuts down payload 
for deintegration and 
specimen storage. User 
oversees payload 
takedown by crew. 


User Integration Plan 
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POIC integrates user 
requirements; SSSC 
integrates user ops with 
systems changes during 
increment handover. 


[Payload returned to 
Earth. ] 


Pre-/Post-Flight Ops 
Office delivers racks 
for deintegration. 
Logistics Ops Office 
delivers payloads to 
customers. 


[Program issues Level 6 
documentation (results of 
debriefings and problem 
reports) } 


User Integration Plan 


[User retrieves payload, 
data, samples, etc. and 
performs analysis, etc. ] 


Users undergo 
debriefings with 
Sponsor, PAM, UOIO, and 
Pre-/Post-Flight Ops 
Office to help the 
Program improve services 
and interfaces, to help 
the user plan his next 
payload, and to help the 
Sponsor determine the 
utility of the Station in 
fulfilling its goals. 


[User publishes results 
or findings and] archives 
data and makes it 
available to other users. 


[Sponsor publishes 
results of the projects 


it supported. ] 
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